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Abstract 


The  chief  barrier  to  the  successful  use  of  electronic  data  interchange  is 
the  difficulty  users  experience  in  integrating  specialized  EDI  software 
with  application  software.  The  goal  of  seamlessly  connecting  one 
company’s  application  with  another  company’s  in  an  unbroken  electronic 
flow  of  data  is  still  far  from  being  realized. 

Recent  workflow  software  products  and  architectures,  such  as  Lotus 
Notes  or  Action  Technologies’  Workflow,  offer  new  possibilities  to  solve 
the  dilemma  of  EDI.  This  white  paper  presents  a generalized  sketch  of 
how  workflow  design  concepts  might  do  this. 
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Electronic  Data  Interchange  and 
Workflow:  Coordinating  Inter- 
Organizational  Business  Processes 


Electronic  Data  Interchange  and  Workflow:  Coordinating 
Action  Across  Organizational  Boundaries 

A 

Introduction 


Electronic  Data  Interchange  (EDI)  has  aided  inter-organization  communi- 
cations since  the  1960s,  when  large  retailers  such  as  Sears,  Roebuck  & 
Company  used  it  to  send  electronic  purchase  orders  to  its  vendors  and 
when  railroad  companies  used  it  it  to  electronically  hand-off  freight  bills, 
manifests,  and  other  documentation  amongst  themselves  when  they  ex- 
changed rail  cars.  EDI  has  sparked  the  imagination  of  many,  promising  to 
interconnect  firms  in  seamless  “extended”  enterprises,  enabling  just-in- 
time  and  quick  response  distribution  strategies. 

Workflow,  in  contrast,  is  a relatively  new  term.  While  vague,  information 
technologists  have  a sense  that  it  is  an  important  conceptual  notion  useful 
in  implementing  information  systems  for  organizations.  Similar  to  sys- 
tems analysis,  workflow  is  a description  of  how  people  interact  to  accom- 
plish a given  task.  With  this  description,  people  can  begin  to  design 
information  systems,  tools,  and  procedures  that  will  enhance  their  produc- 
tivity in  accomplishing  the  given  task. 

The  “established”  technology  of  EDI  and  the  “upstart”  notions  of 
workflow  are  intimately  related.  Together,  they  provide  a powerful  busi- 
ness solution  to  information  technology  users.  Workflow,  in  fact,  provides 
a powerful  framework  that  allows  users  and  vendors  to  put  EDI  to  work 
effectively,  and  to  finally  get  EDI  over  its  brickwall  of  not  being  able  to  be 
integrated  with  an  organization’s  applications. 

Information  service  providers,  in  order  to  provide  successful  business 
solutions  to  their  customers,  need  to  understand  how  EDI  and  workflow  fit 
together.  This  position  paper  explains  the  relationship  between  workflow 
and  EDI.  The  paper  is  directed  to  two  general  audiences:  (1)  EDI  software 
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and  service  providers  who  may  be  new  to  the  concept  of  workflow  and  (2) 
software  developers  already  familiar  with  workflow  concepts  who  may 
not  be  too  familiar  with  EDI. 


B 

Background:  What  is  “EDI”  and  How  Has  It  Evolved? 

EDI  is  the  computer-to-computer  exchange  of  business-related  documen- 
tation in  standardized  data  formats.  The  purpose  of  standardization  is  so 
that  an  application  running  at  one  company  could  exchange  files  with  an 
application  at  another  company,  even  though  the  two  applications  were 
entirely  different  designs,  brands,  and  purposes.  For  example,  a Dun  & 
Bradstreet  purchasing  system  could  create  a standard  file  that  the  company 
would  send,  via  a network,  to  an  order-entry  data  base  and  accounting 
system  custom  built  around  an  Oracle  data  base. 

The  rationale  for  computer-to-computer  exchange  has  been  that  it  elimi- 
nates the  need  to  rekey  data  back  into  a computer  system.  A General 
Electric  estimate  in  the  mid-1980s  held  that  70%  of  all  computer  input  was 
computer  output.  Linking  two  or  more  computers  eliminates  time-consum- 
ing, expensive,  error-prone  labor.  So  went  the  thinking. 

And  so  became  an  industry:  the  EDI  software,  services,  and  standards 
industry. 

At  first,  EDI  was  primarily  provided  by  third-party  value-added  networks. 
They  performed  the  “translation”  from  one  company’s  data  formats  to 
another’s.  But  throughout  the  eighties,  with  the  greater  robustness,  selec- 
tion, and  proliferation  of  generalized  EDI  standards,  software — operated 
by  the  EDI  user — took  on  the  translation  functions. 

To  accomplish  computer-to-computer  linkage,  volunteer  bodies  formed 
around  the  world  to  create  standards  for  the  specific  documents  that  were 
to  be  exchanged.  These  included  such  core  documents  such  as  purchase 
orders,  invoices,  and  shipping  notices.  Over  200  standardized  EDI  mes- 
sage formats  have  been  designed  and  the  number  continues  to  grow. 

Today,  EDI  is  commonly  delivered  to  the  end-user  via  three  kinds  of 
“delivery  modes”  or  product  categories:  EDI  translation  software,  EDI 
network  services,  and  EDI  professional/systems  integration  services. 

Exhibit  1 shows  the  typical  EDI  configuration. 
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EXHIBIT  1 


EDI  software  acts  as  a kind  of  generalized  gateway  between  the 
organization’s  applications  and  the  outside  world.  Communications 
coming  in  from  or  going  out  to  other  organization’s  applications,  are 
converted — translated — into  or  out  of  standard  data  formats.  This  inter- 
mediary translation  stage  allows  all  the  data  formats  of  applications  to 
appear  as  generic/standard  to  other  applications. 

In  1992,  approximately  30,000  users  of  EDI  around  the  world  spent 
approximately  $400  million  to  $600  million  on  these  specific  products  and 
services.  Seventy  five  to  eighty  percent  of  this  expenditure  was  made  by 
U.S.  companies  inside  the  United  States  alone. 

It  is  important  to  note  that  EDI  grew  up  around  software  applications  that 
were  already  in  place.  EDI  was  an  afterthought  to  existing  applications. 
Because  users  have  tried  to  “graft”  EDI  onto  existing  applications,  the 
graft  has  not  taken  very  well. 

1.  The  Problem  with  EDI  Today:  Inability  to  Integrate  with 
Applications 

The  EDI  user  community  has  been  vexed  by  single  problem:  they  are 
unable  to  easily  integrate  the  EDI  translation  software  with  applications 
software.  Seamless  transmission  of  data  from  one  company  to  another  is 
not  happening.  Approximately  80%  to  90%  of  EDI  users  today  simply 
receive  EDI  messages,  print  them  out  on  paper,  then  rekey  the  data  into 
their  applications. 
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In  addition,  most  EDI  users  conduct  EDI  with  less  than  50  companies. 
The  rest  of  their  communications  continues  in  the  paper-based  mode.  So, 
not  only  has  the  current  EDI  architecture  made  it  difficult  for  users  to 
integrate  with  internal  applications,  it  has  made  it  difficult  for  them  to 
integrate  electronically  with  trading  partners. 

In  the  past  few  years,  users  and  vendors  alike  have  wondered  if  EDI  is 
failing  on  its  promise.  To  users,  it  is  a technology  that  isn’t  giving  the 
value  it  promised.  To  vendors,  it  is  a market  that  hasn’t  materialized. 
Rosy  forecasts  in  the  mid-eighties  predicted  that  EDI  would  be  almost  a 
two-billion  dollar  market  by  now.  EDI  isn’t  even  close  to  a billion. 

So  where  can  EDI  go  from  here? 


c 

Workflow:  Capturing  the  Benefit  That  EDI  Had  Always  Promised. 

Workflow  is  a methodology  for  people  to  characterize  work.  It  is  also  a 
technology  (a  collection  of  software  modules)  that  allows  people  and 
automated  information  processing  systems  to  interact  in  ways  that  best 
leverages  the  capacities  of  each.  Thinking  in  terms  of  “workflows”  solves 
most  of  today’s  problems  with  EDI.  Workflow  thinking  allows  people  to 
design  and  implement  effective  EDI  systems.  In  other  words,  workflow 
thinking  allows  people  to  integrate  EDI  with  applications  and  with  other 
communication  technologies  (including  facsimile,  E-mail,  voice,  “real 
time”  processes,  etc. — even  computer/communication  technologies  that 
have  yet  to  be  invented). 

1.  Workflow:  The  Concept 

Several  kinds  of  workflow  products  are  on  the  market  today:  AT&T/NCR, 
Digital  Equipment  Corporation,  Lotus  Development  Corporation,  Corpo- 
rate Memories  Inc.,  and  others.  While  these  help  to  substantiate  a “mar- 
ket,” we  believe  the  workflow  concept  of  Action  Technologies,  Inc.  is  the 
definitive  product.  ATI’s  workflow  is  different — and  more  powerful — 
than  the  others  because  it  takes  its  primary  and  over-riding  purpose  as: 
customer  satisfaction. 

In  all  work  situations,  there  are  two  fundamental  players:  a customer,  who 
has  asked  for  something,  and  a supplier  or  performer,  who  fulfills  the 
customer’s  request.  There  may  be  many  intermediary  steps  and  delega- 
tions of  work  involved  along  the  way  in  satisfying  the  original  customer’s 
request.  These  intermediary,  delegated  steps  themselves,  however,  can  be 
characterized  as  more  workflows,  each  with  their  own  customer  and 
performer.  Work  and  information  systems  can  be  designed  using  this 
concept. 
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Exhibit  2 shows  the  basic  “moves”  involved  in  a workflow. 


EXHIBIT  2 


Actions  that  accomplish  work  are  “set  in  motion”  through  a finite  set  of 
conversational  moves,  and  they  are  listed  in  Exhibit  2.  Work  begins  with  a 
person  making  a request.  The  performer  has  a variety  of  options  in  re- 
sponding to  the  request:  to  promise  to  do  it,  to  decline  to  do  it,  to  make  a 
counteroffer,  and  so  on,  as  shown.  If  the  performer  promises  to  do  what  is 
requested,  he  or  she  may,  in  turn,  make  a request  to  another  person  (an 
employee  in  the  same  organization)  to  do  some  related  task.  This  sets  up 
another  workflow  with  a customer  and  a performer. 

Completion  of  the  work  is  accomplished  when  the  performer  informs  the 
customer  that  the  work  is  done  and  the  customer,  after  examining  the 
work,  declares  that  it  is  satisfactory. 

The  whole  work  cycle  can  be  depicted  as  a loop  that  begins  with  a cus- 
tomer request  and  ends  when  the  customer  announces  satisfaction.  The 
basic  workflow  loop  is  shown  in  Exhibit  3. 
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EXHIBIT  3 


The  Workflow  Loop 


Customer 

Asks  for  report 


Customer 

Declares 

satisfaction 


Performer 

Agrees  to  do  it 


Performer 

Reports  it  done 


2.  The  Relationship  Between  EDI  and  Workflow 

Most  workflow  tools  today  are  implemented  within  a single  organization. 
Nevertheless,  and  perhaps  more  significantly,  workflow  occurs  among 
organizations.  This  is,  of  course,  the  domain  of  EDI.  EDI  data  formats 
allow  companies  to  streamline  the  flow  of  data  between  mutually  corre- 
sponding business  functions  across  organizational  boundaries.  For  ex- 
ample, the  EDI  invoice  data  format  allows  the  accounts  receivable 
function  of  one  company  to  “speak”  to  the  accounts  payable  function  of 
the  company’s  customer.  A standardized,  electronic  invoice  is  created  by 
the  accounting  department  of  the  supplier  company  and  sent  to  the  ac- 
counting department  of  the  buying  company. 

Yet  EDI  standard  data  formats,  as  currently  conceived,  lack  the  integrated 
vision  of  conversational  moves  that  achieve  customer  satisfaction.  As 
such,  the  purpose  of  any  given  EDI  message  is  not  connected  to  the  larger 
work  context.  How  the  message  is  to  be  integrated  with  the  general  func- 
tioning of  the  organization  is  not  clearly  discernible.  This  is  at  the  root  of 
why  company  integration  through  EDI  has  not  been  attained. 
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A commercial  trade  is  the  exchange  of  two  promises.  A buyer  and  a seller 
make  promises  to  each  other.  Usually,  one  party  promises  a good  or 
service  and  the  other  party  promises  cash.  Each  party  is  the  customer  for 
the  promise  of  the  other.  Given  this  understanding,  a purchase  order  can 
be  considered  a request  and  an  implicit  promise  to  pay.  Its  acknowledg- 
ment is  a promise  to  provide  the  requested  product  or  service. 

Today’s  EDI  message  formats  can  be  classified  according  to  workflow 
moves.  Exhibit  4 shows  this  classification. 


EXHIBIT  4 


EDI  Transaction  Sets  Can  Be  Designed  According 
to  Workflow  Moves,  Which  Are  Finite  in  Number 


Workflow  Move 

Corresponding  XI 2 Transaction  Sets 

Request 

Purchase  order 
Request  for  quotation 
Invoice 

Payment  order 

Offer 

Response  to  request  for  quotation 
Inventory  advice 

Agree  to  -i 

request/offer  / Promise 

P.O.  acknowledgment 
Contract  award 

Decline  request/offer 

No  response  from  trading  partner 

Counteroffer 

P.O.  change 

Cancel 

Payment  cancellation  request 

Report  completion 

Operating  expense  statement 
Payment  status  report 

Inform 

Product  activity  data 
Report  of  test  results 
Trading  partner  profile 

Since  EDI  messages  weren’t  designed  according  to  the  conversation-for- 
customer- satisfaction  in  mind,  they  don’t  perfectly  fit  the  model.  In  many 
cases,  EDI  messages  are  lacking  equivalent  workflow  messages,  such  as 
declining  a purchase  order. 
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It  is  possible  to  superimpose  the  workflow  model  on  two  companies  that 
are  trading.  Exhibit  5 shows  this. 


EXHIBIT  5 


In  Exhibit  5,  you  can  see  how  the  workflow  design  methodology  gives  a 
context  for  EDI  messages.  It  gives  “meaning”  to  the  messages.  A 
workflow  management  software  module  can  look  at  the  messages  and 
determine  what  work  steps  need  to  be  done  next,  what  person  or  applica- 
tion to  route  messages  to,  and  who  or  which  software  process  to  involve  in 
the  next  work  step. 

With  the  workflow  concept,  EDI  messages  become  just  tokens  in  a larger 
workflow.  They  are  not  ends  in  themselves.  Today’s  EDI  integration 
attempts  place  EDI  messages  as  ends  in  themselves.  This  is  wrong. 
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Users  implement  EDI  to  be  more  effective  competitors,  to  have  better 
relationships  with  customers,  and  to  be  more  efficient  with  suppliers — not 
to  transfer  files  per  se.  Effective  fie  transfer  among  organizations  and 
among  different  computer  environments  is  important  but  just  a component 
of  a larger  objective:  to  be  more  competitive. 

EDI  is  a technology  that  fits  into  a larger  solution.  The  solution  is  both 
competitiveness  and  customer  satisfaction.  Workflow  is  a method  and 
technology  which  allows  the  organization  to  design  and  implement  cus- 
tomer satisfaction. 


D 

Workflow  Management  Architecture  for  EDI 

Action  Technology’s  Workflow  Management  System  architecture  is 
designed  for  interoperability  among  different  applications  and  across 
diverse  platforms,  integrating  the  coordination  of  specific  applications 
along  with  system  enhancements  and  utilities  from  users  and  third-party 
developers. 

1.  Workflow  Management  Architecture 

The  overall  architecture  consists  of  one  or  more  client  applications  (called 
workflow-enabled  applications)  and  the  structures  and  components  that 
enable  them  to  interact  with  the  workflow  management  server  and  receive 
services  from  it.  Exhibit  6 shows  the  major  components  of  a Workflow 
Management  System. 
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EXHIBIT  6 


Workflow  Management  System  Architecture 


Design  workstation 


Workflow- 

enabled 

applications 


STF 

processors 


STF  - Standard  Transaction  Format 


Workflow 

language 

interpreter 


Agent 

processor 


Workflow 

processor 


Definitions 
data  base 


Transactions 
data  base 


Workflow  management  system 

Source:  Action  Technologies,  Inc. 


Workflow-enabled  applications 

The  goal  of  the  Workflow  Management  System  is  to  provide  workflow 
capabilities  to  new  and  existing  computer  applications.  Adding  or  inte- 
grating an  existing  or  new  application  is  referred  to  as  “workflow-en- 
abling.” 

Workflow-enabled  applications  are  of  three  types: 

1.  Workflow-initiating  applications. 

An  example  of  a workflow-initiating  application  would  be  an  existing 
order-entry  application  which  has  been  modified  to  initiate  a fulfillment 
workflow.  The  task  of  the  order-entry  application  is  complete  once  the 
fulfillment  workflow  takes  over  and  starts  a sequence  of  actions  to  verify 
the  new  order,  define  customized  requirements,  alert  manufacturing,  etc. 
This  level  of  integration  can  be  done  with  little  or  no  modification  to  the 
existing  system. 
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2.  Workflow-participating  applications. 

In  the  order-entry  example  discussed  above,  the  participating  applications 
are  those  that  perform  the  details  of  the  fulfillment  process.  The  order- 
entry  application  first  initiates  a workflow  to  verify  credit,  for  example,  by 
sending  an  E-mail  form  to  the  credit  manager,  to  which  she  or  he  can 
respond  by  checking  Yes  or  No.  The  addition  of  those  buttons  to  an 
existing  e-mail  form,  plus  the  work  of  defining  Yes  or  No  as  they  are  to  be 
understood  in  this  case  by  the  workflow  processor,  are  the  only  steps 
required  to  workflow-enable  this  aspect  of  the  applications. 

3.  Workflow  management  applications. 

Workflow  management  applications  provide  managerial  views  and 
actions,  in  addition  to  the  operational  ones  needed  to  conduct  the  work.  In 
the  above  order-entry  example,  an  application  that  had  workflow  manage- 
ment built-in  could  be  used  to  keep  track  of  fulfillment  cycle  times, 
sources  of  breakdown,  etc.  The  candidate  review  example  includes 
workflow  management. 

STF  Processors 

STF  Processors  translate  between  an  application’s  native  data  format  and 
the  Standard  Transaction  Format  of  the  Workflow  Language  Intepreter. 
STF  Processors  isolate  the  Workflow  Management  Server  from  the  inter- 
face used  by  the  application  and  provide  a layer  for  integrating  different 
protocols  and  technologies.  By  providing  an  appropriate  STF  Processor, 
any  existing  data  base,  messaging,  or  networking  system  can  be  incorpo- 
rated into  a workflow  management  network.  If  an  application  communi- 
cates by  writing  to  a data  base,  for  example,  the  STF  Processor  will  read 
the  data  base  and  look  for  the  records  that  hold  STF  transactions. 

This  architecture  makes  it  possible  for  existing  line-of-business  applica- 
tions, data  bases,  networks,  and  protocols  to  be  orchestrated  by  the 
ActionWorkflow  system.  Organizations  already  have  tools  in  place  to 
management  parts  of  tasks,  and  parts  of  workflows.  It  is  an  important 
requirement  of  a workflow  system  to  integrate  with  the  existing  infrastruc- 
ture, or  the  benefits  will  not  outweigh  the  costs  of  moving  to  it. 

There  are  three  types  of  STF  processors: 

1.  Message-based 

Message-based  applications  interact  with  the  Workflow  Management 
System  by  sending  and  receiving  messages.  The  STF  Processor  receives 
the  messages  from  applications  and  interacts  directly  with  the  Workflow 
Management  Server.  Similarly,  it  constructs  messages  to  be  sent  back  to 
the  application.  Message-based  STFs  are  independent  of  the  message 
transport.  Our  current  implementations  use  MHS  as  the  messaging  sys- 
tem. 
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2.  Data  base-based. 

The  client  application  writes  and  modifies  records  in  an  external  data  base 
that  is  concurrently  accessed  by  an  STF  Processor  that  has  been  built  for 
the  particular  data  base  platform.  Applications  initiate  and  participate  in 
workflows  by  modifying  records  in  this  shared  data  base.  The  STF  Pro- 
cessor monitors  changes  to  the  data  base  and  interacts  with  the  Workflow 
Management  Server  for  recording  and  updating  transactions.  Applications 
can  manage  workflow  and  business  processes  by  querying  this  shared  data 
base  to  obtain  reports  about  the  status  of  the  workflows.  We  have  imple- 
mented transaction  data  bases  in  Lotus  Notes  and  on  SQL  servers. 

3.  Process-based. 

In  the  interprocess  communication  STF  interface,  a client  application 
receives  services  from  a server  by  making  a process-to-process  service 
request  (a  remote  procedure  call,  for  example).  In  this  case,  the  STF 
structures  are  embedded  in  the  parameter  blocks  of  the  service  request  and 
service  result  calls. 

Workflow  Management  Server 

The  Workflow  Management  Server  uses  stored  definitions  of  the 
workflow  structure  and  of  the  history  of  transactions  to  interpret  and 
initiate  acts.  It  comprises  a number  of  interacting  components: 

a)  Definitions  Data  Base 

This  data  base  describes  the  workflow  of  the  organization.  The  definitions 
include  several  basic  structures.  The  core  is  the  set  of  loop  types  and  act 
names  with  associated  forms.  For  example,  the  loop  type  “Manage  candi- 
date review”  would  have  an  associated  form,  as  shown  in  Figure  4,  and  an 
“accept  candidate”  act  as  one  of  its  ways  of  reaching  completion.  The 
definitions  data  base  also  specifies  the  linking  relationships  connecting  the 
different  loops  and  the  actions  to  be  taken  automatically  by  the  agent 
processor. 

The  linking  relationships  are  used  to  generate  the  appropriate  sets  of  “net 
actions”  for  each  participant  in  the  workflow  process,  and  for  automation. 
They  can  be  of  several  kinds: 

1.  Subordinate  workflow  loops: 

In  order  to  complete  a part  of  one  workflow,  it  is  necessary  to  initiate  and 
complete  a subsidiary  one.  For  example,  in  order  to  do  the  review  it  is 
necessary  to  schedule  interviews. 
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2.  Independent  triggered  workflow  loops: 

An  action  in  one  workflow  triggers  the  initiation  of  another,  which  pro- 
ceeds independently.  For  example,  in  a sales  workflow  the  selling  of  an 
item  from  stock  may  trigger  reordering,  but  the  reordering  is  not  a part  of 
completing  the  sale  that  triggered  it. 

3.  Resolving  workflow  loops: 

The  decision  as  to  which  action  to  take  in  one  workflow  requires  the 
initiation  and  completion  of  another  workflow.  For  example,  a credit 
approval  must  be  received  before  accepting  or  rejecting  an  order. 

In  each  of  these  cases,  there  may  be  several  triggered  loops  of  a given  kind 
instead  of  just  one,  with  concurrency  relationships  among  them.  In  the 
candidate  review  example,  all  workflow  loops  for  interviews  are  started  in 
parallel  at  the  moment  the  agreement  is  reached  in  the  main  loop.  The 
definition  of  the  process  indicates  that  the  performance  phase  of  the  main 
loop  is  completed  once  all  the  interview  loops  are  complete. 

b)  Transactions  Data  Base 

This  data  base  contains  the  history  of  completed  workflow  loops  and 
workflows-in-progress.  It  is  accessed  both  for  carrying  out  transactions 
and  for  providing  status  reports  and  overview. 

c)  Workflow  Language  Interpreter 

The  Workflow  Language  Interpreter  receives  service  requests  from  STF 
Processors  in  the  form  of  workflow  language  constructs:  workflow 
declarations,  workflow  actions,  and  requests  for  workflow  management 
services.  It  instructs  the  workflow  processor  to  calculate  workflow  states 
and  next  actions  based  on  specified  criteria  (such  as  the  current  state  of  the 
workflow  and  the  role  of  the  person  taking  an  action).  It  takes  actions  and 
makes  reports  based  on  the  calculations  of  the  workflow  processor  and  the 
logic  of  the  workflow  definitions. 

d)  Workflow  Processor 

The  workflow  processor  generates  and  manages  transaction  records  in  the 
transactions  data  base,  which  keeps  track  of  the  current  state  and  history  of 
the  workflow,  organized  according  to  the  component  loops  and  associated 
completion  times. 

e)  Agent  Processor 

The  agent  processor  maintains  a queue  of  events  and  times  to  trigger 
workflow  actions  that  have  been  specified  in  the  definition.  We  have 
taken  the  approach  of  incremental  automation,  initially  assuming  human 
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action  at  each  point  and  then  introducing  a program-determined  action  at 
any  point  where  rules  can  be  effectively  specified.  Agent  code  is  written 
in  the  workflow  definition  language  and  initiated  on  the  basis  of  the 
workflow  type  and  act  that  triggers  it.  It  can  take  actions  both  within  the 
workflow  structure  (making  acts  and  initiating  new  workflows)  and  in 
other  functions  (printing  reports,  sending  E-mail  messages,  running  other 
applications,  etc.). 

There  are  three  ways  in  which  agents  are  triggered: 

1.  Triggering  act 

For  example,  a cancellation  in  a particular  workflow  initiates  a request  to  a 
manager  to  deal  with  problems  caused  by  cancellation. 

2.  Status  changes  in  a workflow 

For  example,  a workflow  moving  to  the  state  “completed”  may  trigger 
actions  to  cancel  all  the  subsidiary  workflows  in  progress,  whether  or  not 
the  termination  resulted  from  a cancellation,  success,  failure,  etc. 

3.  Incomplete  times 

For  example,  a follow-up  request  to  a performer  may  be  initiated  when  the 
time  for  completion  of  a loop  has  been  reached  without  a declaration  of 
completion. 

Design  Workstation 

The  design  workstation  is  a separate  application  which  is  used  to  generate, 
modify,  and  maintain  the  definitions.  We  have  developed  a graphical 
notation  for  high-level  workflow  maps  and  have  implemented  interactive 
structured  drawing  tools  for  creating  and  manipulating  those  maps,  which 
can  be  used  for  business  process  redesign,  both  with  and  without 
workflow  management  system  development. 

2.  EDI  Components  in  Workflow  Management  Architecture 

Today’s  EDI  architecture  (translation  and  mapping  software,  application 
software,  network  services,  standardized  data  formats,  and  other  compo- 
nents) fits  into  this  workflow  management  system  in  a way  that  truly 
solves  the  EDI  problem  of  integration. 

Integration  with  other  applications  always  goes  through  the  workflow 
management  system,  instead  of  directly  from  the  translation  software  via 
an  API  to  the  application,  as  current  EDI  integration  does. 

Exhibit  7 shows  the  current  EDI/application  integration  architecture 
compared  to  integration  using  the  workflow  architecture. 
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EXHIBIT  7 


Business  Process  Integration — Today’s  EDI 
Architecture  versus  EDI-Workflow  Architecture 

Conventional  EDI  integration 


Integration  achieved  through  EDI  and  workflow  combined 


EDI  STF 
A.K.A. 
translation 
software 


(^et^rk^ 


Source:  INPUT 


EDI  components  fit  into  workflow  in  many  locations  of  the  model.  EDI 
translation  software,  as  conceived  of  today,  partly  resides  as  one  kind  of 
STF  and  partly  as  definitions  in  the  data  base  of  the  workflow  manage- 
ment system. 

Today’s  EDI  translators  contain  data  definitions  and  roles  (in  the  form  of 
trading  partner  profiles)  that  are  better  placed  in  the  workflow  manager 
component. 

The  Standard  Transaction  Format  processor — as  an  EDI  document  transla- 
tor— identifies  the  customer  by  checking  with  the  definitions  data  base  and 
identifies  the  workflow  type  (request,  promise,  etc).  In  some  cases,  the 
definition  data  base  may  reside  outside  of  the  organization,  such  as  the 
UPC  catalog  data  bases  that  identify  product  merchandise  with  unique  bar 
code  identifiers. 
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Exhibit  8 shows  the  workflow  architecture  that  supports  receiving  an 
electronic  purchase  order. 


EXHIBIT  8 


Components  of  a Purchase  Order  Business  Process 


External  data  bases 

(Credit  authorization,  UPC  catalog,  community  EDI  system,  trading  partner  profiles) 

Source:  INPUT 


E 

EDI:  A Technology  for  Satisfying  Customers 

Workflow  architecture  can  save  EDI  from  its  current  difficulty  of  being 
integrated  with  a company’s  internal  software  applications.  The  usefulness 
of  EDI — streamlining  the  exchange  of  data  that  is  reused  in  different 
applications — can  now  be  truly  leveraged  using  the  workflow  concept. 

Successful  organizations  are  those  that  increase  the  recurrence  of  product 
sales  and,  consequently,  the  collection  of  payments.  To  increase  the 
recurrence  of  sales,  organizations  must  understand  that  intercompany 
exchange  is  effectively  done  by  managing  a sequence  of  commitments 
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among  people.  To  diagram  and  build  IS  systems  that  initiate,  receive  and 
manage  these  acts  of  commitment,  workflow  technology  is  the  perfect 
tool. 

The  reciprocating  flows  of  products  and  payments,  as  diagramed  in  exhibit 
9,  can  be  modeled  according  to  workflow  (as  shown  in  exhibits  5 and  8). 
With  the  workflow  framework,  systems  integrators  can  now  build  commu- 
nication-information systems  that  directly  support  the  recurrence  of  sales. 
Consequently,  workflow  is  an  essential  context  for  successfully  integrat- 
ing EDI  as  part  of  a communications  link  between  the  internal  business 
procedures  of  companies. 

Effective  EDI  implementation  requires  looking  at  the  exchanges  between 
two  organizations  as  a workflow.  A workflow  framework  identifies  who  is 
trying  to  accomplish  what  for  whom.  Establishing  this  allows  users  to 
implement  information  systems  that  will  accomplish  their  business  objec- 
tives. It  will  allow  them  to  see  where  the  appropriate  EDI  transfers  should 
take  place  and  what  people  and  applications  should  be  involved. 


EXHIBIT  9 


Flow  of  Products  and  Payments 

Products 
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